I am fascinated about compilers and low-level programming since my undergrad when I first read the Dragon Book. To be honest, there were many theoretical concepts from the book that were not clear to me at that time. Every time I read that book, I learn something new out of it that I didn’t understand before. The theory was great, but back in my undergrad, I did not build a real compiler. I always had an urge to build a compiler of my own to see how various moving pieces come together and become the foundation of the entire computer industry. During my Master’s I did build a XML based intermediate language. It was super fun project since it gave me lot of exposure to the vast problem space a compiler developer needs to solve and think about. By the end of the project, I had good understanding of front-end and basic runtime needed for programming language to function. However, there were still crucial back-end pieces of compiler that I did not get chance to study and understand. Just-in-time (JIT), optimizations, register allocator, machine instructions encoding and garbage collector (GC) forms the backbone of compiler and can be found in any industry implementation of programming language.

I joined Microsoft in Windows Live ID team. The work in the team was great but my hunger for compilers led me to join the Microsoft’s Javascript runtime “Chakra team”. Here, I got an opportunity to work with super smart people who were “the experts” in compiler domain. Imagine working with someone who wrote Microsoft’s VC++ from last 15 years or passing Anders Hejlsberg frequently in the hallway. Although I never worked with Anders in person, but it was great to see such an influential person in programming language community and someone whose youtube tech videos I used to watch often while in grad school. This was a great opportunity to learn all the phases of compiler written in production ready code base. Not only was this my first time working in C++, I also got my hands-on various debugging and analysis tools like windbg and performance explorer that I had always shy away from. There was a huge learning curve in front of me technically, in compiler domain and javascript programming language. Just in few months I realized that the theory-based compilers built in school were just a tip of the iceberg in comparison to the ones built by software companies. I got lot of good opportunities in this team to solve challenging problems like testing and debugging JIT generated code, investigating memory leaks in GC, making node.js run with Chakra engine and finding and fixing performance bottlenecks in runtime and JIT. After working for almost 5 years in Chakra, I got attracted to the new kid on the block, “Artificial Intelligence”. I wanted to join a team which works in machine learning but at the same time has its roots back to programming language/compilers. Prose was a perfect match for me. Prose team worked on programming by examples; learning and synthesizing programs based on user given input and output examples. Once program is learned, I worked on various translators that translated those programs to various programming languages like Python, Java, etc. After working in PROSE for almost 2 years, I decided to switch back to the low-level compiler work. This is when I got an opportunity to join the JIT team of .NET Runtime.

When I was in Windows Live team 8~9 years back, I attended a talk by Jeffrey Richter on “CLR via C#”. I was super impressed with the concepts of CLR and spent few months reading books. I wanted to join such team, but I was not prepared for it. But after all these years, I finally got chance to join the .NET runtime’s JIT team. I am super excited about it because I always wanted to get my hands on JIT, but never got suitable opportunity to work on bigger projects. It is a privilege to be part of this team, not only because every .NET user on the planet will use the code we write, but there are lot of challenging projects to work on. For next few months, I will be evaluating the ARM64 performance of .NET 5.0 in comparison with that of x64. I hope my performance analysis skillset and expertise that I learned in the past prove useful here. I will cover some of the interesting ARM64 performance issues I find on the way in a separate blog post.

Namaste!